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ABSTRACT 

The design of metaprogramming languages requires appre¬ 
ciation of the tradeoffs that exist between important lan¬ 
guage characteristics such as safety properties, expressive 
power, and succinctness. Unfortunately, such tradeoffs are 
little understood, a situation we try to correct by embark¬ 
ing on a study of metaprogramming language tradeoffs us¬ 
ing tools from computability theory. Safety properties of 
metaprograms are in general undecidable; for example, the 
property that a metaprogram always halts and produces a 
type-correct instance is Il^-complete. Although such safety 
properties are undecidable, they may sometimes be captured 
by a restricted language, a notion we adapt from complex¬ 
ity theory. We give some sufficient conditions and negative 
results on when languages capturing properties can exist: 
there can be no languages capturing total correctness for 
metaprograms, and no ‘functional’ safety properties above 
S§ can be captured. We prove that translating a metapro¬ 
gram from a general-purpose to a restricted metaprogram¬ 
ming language capturing a property is tantamount to prov¬ 
ing that property for the metaprogram. Surprisingly, when 
one shifts perspective from programming to metaprogram¬ 
ming, the corresponding safety questions do not become sub¬ 
stantially harder — there is no ‘jump’ of Turing degree for 
typical safety properties. 

General Terms 

metaprogramming, metalanguages, program generators 

1. INTRODUCTION AND OVERVIEW 

If one starts the clock at Konrad Zuse’s insight that a 
computer could prepare its own instructions, metaprogram¬ 
ming is nearing 65 years old [4]. Happily, it shows no sign of 
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retiring and instead seems to grow in prominence with each 
passing decade. As a sort of uninvited Festschrift contribu¬ 
tion I propose to turn a critical eye to it, investigating its na¬ 
ture both good and bad by characterizing tradeoffs between 
facets of interest: safety, power, succinctness, and so forth. 
This paper was motivated in part by ongoing controversy in 
the program generation community on how metaprogram¬ 
ming tools should approach the tradeoff between safety and 
power, or even if such a tradeoff exists. Representative of 
such tradeoffs are the strong safety guarantees of MetaML 
[25, 28], the unrestrained power (but compromised safety 
properties) of C+-1- template metaprogramming [8], and the 
moderate approach of SafeGen [14]. Similar controversy ex¬ 
ists in the design of programming languages, where there is 
endless contention regarding the ‘proper’ tradeoff between 
safety properties and expressive power. Early programming 
systems of the 1950s often incorporated facilities for syntax 
extensions and customized code generators (e.g., [26]). The 
1971 programming language ELI, possibly the very first to 
implement generics, allowed arbitrary expressions to appear 
where a type name was expected. The compiler dealt with 
such expressions by invoking a built-in interpreter to per¬ 
form partial evaluation [30, 3, 12]. C+-1- is very much in 
the vein of such languages: powerful generics facilities with 
weak safety properties. Type-safe languages such as ML and 
Java represent an opposite philosophy, providing restricted 
forms of generics with strong safety guarantees. 

A more thorough understanding of such tradeoffs would 
be beneficial. In computational complexity there is a well- 
established tradition of using theory to characterize trade¬ 
offs: between space and time, time and randomness, com¬ 
munication and space, space and reversibility, and so forth. 
A similarly methodical investigation would be useful for the 
field of metaprogramming— to map out the lay of the land, 
so as to have a solid theory of costs and benefits when mak¬ 
ing design decisions. Part of this we can borrow from the 
existing literature on tradeoffs in programming languages 
between power and succinctness. For tradeoffs concerning 
safety properties we turn to computability theory, which has 
striking explanatory power for metaprogramming tradeoffs. 

It is fruitful to approach the study of metaprogramming as 
the study of generalization in software. We view a metapro¬ 
gram as a generalization of a set of concrete instances: a 
parser generator generalizes a class of parsers, for example. 
To reason about many forms of generalization in a common 
framework, we will adopt some uniform terminology: 

• A metalanguage is a language in which we define gen- 



eralizations. 

• A generator is the expression of a generalization in a 
metalanguage. 

• An instance is the output produced by a generator 
when evaluated on some input (e.g., parameters or 
source program). 

The most powerful metalanguage possible is, of course, a 
general-purpose, Turing-complete programming language, as 
used in general source-to-source metaprogramming. As we 
move to more restricted metalanguages, the properties we 
can guarantee increase, and expressive power decreases. For 
instance, parametric polymorphism can be usefully viewed 
as defining a metalanguage for expressing generic functions: 
the familiar function map— 

map : (a —> (3, list a) — * list (3 

generalizes over the concrete set of map functions obtained 
by substituting any types for a, (3. Parametric polymor¬ 
phism is highly restrictive, but if correctly implemented, 
type-safe. In such examples we apply the term ‘generator’ 
in a formal sense, representing a translation from a metalan¬ 
guage to concrete instances, without the requirement that 
code duplication take place in the implementation. This 
terminology is incidentally consistent with early papers on 
generics that called them type generators [20]. 

If one metalanguage can express more generalizations than 
another, we say it has greater expressive power. By consid¬ 
ering the properties of metalanguages of varying power, we 
can gain insight into the tradeoffs that exist between facets 
such as power, safety, and succinctness. 

Some important themes are nicely illustrated by the sim¬ 
ple example of regular expressions, which should be familiar 
to most readers. Regexps have the nice property that they 
capture exactly the computations realizable by deterministic 
finite automata; this guarantees every regexp can be imple¬ 
mented efficiently and we can check equivalence of their DFA 
representations in 0(n log n) time [13]. Practical implemen¬ 
tations of regexps differ from theory by introducing general¬ 
izations of frequently used patterns. For instance one can of¬ 
ten write “[a-z]” to mean “[abcdefghijklnmopqrstuvwxyz]”. 
The generalization “[C1-C2]” is not definable in the language 
of regular expressions, i.e., we cannot equate “[C1-C2]” with 
some regular expression “s” that produces the appropriate 
sequence of characters given arbitrary ci and C 2 . Instead 
it acts as a sort of limited escape into a slightly stronger 
formalism. This escape serves to compress typical expres¬ 
sions by factoring out a commonly occurring motif that is 
‘incompressible’ in the weaker formalism of regular expres¬ 
sions. We can view “[a-z]” as an invokation of a generator 
that produces the instance “[abc...z]”. The generator has 
the desirable property that every instance it produces is 
a valid regular expression, so the escape into the stronger 
formalism does not contaminate the ‘nice’ properties of reg¬ 
exps. Against all this praise we note that when one nears the 
boundary of what is ‘natural’ to express in regexps, monsters 
are quickly encountered. For instance, the expression— 

((a|&a(aa)*b)(6(aa)*6)*(a|&a(aa)*&)|6(aa)*b)* • • • 

• • • (a\ba(aa)*b)(b(aa)*b)* 

recognizes all strings with an even number of b’s and an 
odd number of a’s. This set of strings is more easily recog¬ 


nized by a simple program in a general-purpose language. 
However, in such a setting we have no guarantee that the 
language being recognized is, in fact, regular. Moreover, 
suppose we start with a program in a general-purpose lan¬ 
guage that recognizes a regular language, and rework it into 
a regular expression. This reworking is tantamount to prov¬ 
ing that the set of strings accepted by the program is regular, 
and is as difficult to carry out as a proof. The resulting loss 
in succinctness (i.e., explosion in size) cannot be bounded by 
any computable function; one can say with confidence that 
there are C programs deciding regular languages that require 
IO 100 times more characters to write down when turned into 
regular expressions. This result is due to pioneering work of 
Manuel Blum on succinctness tradeoffs [2]. 

The themes encountered in the above example have ana¬ 
logues in the design of metalanguages. In designing a meta¬ 
language, one may have in mind a safety property it is desir¬ 
able to guarantee: type-safety or termination, for example. 
In the ideal case a metalanguage can be found that ‘cap¬ 
tures’ exactly the property: any generator expressed in the 
metalanguage has the property, and any generator compati¬ 
ble with the property can be expressed in the metalanguage. 
Such restricted languages generally entail a loss in succinct¬ 
ness compared to a general-purpose language. When it is not 
possible to capture exactly a safety property with a metalan¬ 
guage, one is faced with two possible strategies. The first 
is to devise a metalanguage that guarantees the property 
but sacrifices expressive power; the second is to sacrifice the 
safety property in favour of expressive power. These strate¬ 
gies are exemplified by the functional language approach to 
generics, in which type safety is paramount, and the ap¬ 
proach of languages such as C++ and ELI, where one has 
unlimited expressive power for generics but type safety is 
compromised. In either strategy there is the possibility of 
‘chasing’ the property by extending the language so as to 
gradually recoup expressive power or safety. Parametric 
polymorphism gives way to F-bounded polymorphism gives 
way to type classes, and so forth. In C++ there is a growing 
effort to introduce some stronger (but optional) type safety 
mechanisms for generics. As the parade of language features 
extends to infinity we may approach arbitrarily closely hav¬ 
ing both the safety property and unlimited expressive power. 

1.1 Contributions 

This paper makes three kinds of contributions. First, we 
initiate a new research programme of characterizing trade¬ 
offs in metalanguages. Second, we gather scattered infor¬ 
mation about tradeoffs relevant to metaprogramming and 
make it accessible. Third, and most importantly, we prove 
an array of results on tradeoffs in metaprogramming, most 
previously unknown. We prove that multi-stage generators 
are no more powerful than single-stage generators (Proposi¬ 
tion 5.1). In general, deciding safety properties of generators 
is not possible. For example, the ‘partial correctness’ prop¬ 
erty of whether generators written in a general-purpose lan¬ 
guage always produce instances satisfying a nontrivial safety 
property is undecidable. The stronger property of total cor¬ 
rectness, i.e., generators always halt and produce a safe in¬ 
stance is n^-complete (Proposition 6.3). The more interest¬ 
ing problem is devising metalanguages that capture safety 
properties. We prove that reworking a generator from a 
general-purpose metalanguage to a restricted metalanguage 
capturing a property is tantamount to proving that prop- 



erty (Theorem 6.2). We also give some sufficient conditions 
and negative results on when languages capturing properties 
can exist; for example there can be no languages capturing 
total correctness for generators, nor languages capturing to¬ 
tality, and no ‘functional’ safety properties above £3 can be 
captured. We review the major results on succinctness in 
programming languages, and show that bounded succinct¬ 
ness is only plausible for languages capturing properties in 
IlD. We ask when “going meta” implies a jump in the de¬ 
gree of undecidability of a property; surprisingly, interesting 
safety properties do not become much harder when we go 
from programming to metaprogramming (Section 8 ). Fi¬ 
nally, we show the existence of two distinct strategies for 
‘safe’ metaprogramming: one safe, approximating powerful 
languages conservatively from below, and one powerful, ap¬ 
proximating safe languages from above. 

2. A CATALOGUE OF TRADEOFFS 

We propose to investigate metalanguages and the trade¬ 
offs they represent, restricting ourselves to tradeoffs suited 
to theoretical investigation . 1 We can compare metalanguages 
according to how they trade off important characteristics or 
facets: 

• The expressive power of the metalanguage, i.e., what 
generators we can define in it; 

• The safety properties we are guaranteed about the in¬ 
stances; 

• Succinctness, that is, how long the inputs or parame¬ 
ters must be to produce instances of interest; 

• The time and space complexity of “running” the gen¬ 
erator to produce an instance. 

There are additional facets not investigated in the present 
paper, but deserving of future research: 

• The decidable properties of instances; 

• The class of problem domains for which we can write 
generators that let us make programs shorter (i.e., 
compress them [29]). 

• The difficulty of finding inputs to a generator that will 
produce a particular instance, i.e., inversion of a gen¬ 
erator; 

• The effort required to devise an appropriate generator, 
given an instance or class of instances over which we 
wish to generalize. 

Not surprisingly, we are not free to choose the best pos¬ 
sible properties among the above facets. Rather, fixing one 
property constrains our other choices. For example, the fol¬ 
lowing two properties of a metalanguage are at once desir¬ 
able and irreconcilable: 

1 There is an entire family of important tradeoffs not 
amenable to theoretical investigation: those dealing with 
humans, computers, and their tendency to confuse one 
another. For human factors issues the reader is recom¬ 
mended to the wonderful Cognitive Dimensions framework 
of Thomas Green and his collaborators that distills decades 
of research in psychology of programming into digestible 
tradeoffs [ 10 , 1 ], 


1. The ability to describe any possible generator; 

2. The safety property that every generator will produce 
its output and stop. 

The first property implies Turing-completeness; the sec¬ 
ond property implies a metalanguage that is necessarily sub¬ 
recursive (not Turing-complete). 

2.1 A tour of tradeoffs 

To familiarize ourselves with the nature of these tradeoffs, 
let us take a brief tour through the above facets. To simplify 
we shall embark on a one-dimensional tour starting with a 
universal (Turing-complete) metalanguage and descending 
down a chain to primitive recursive generators, exponential 
time generators, polynomial time, and so forth down to very 
weak formalisms such as CFGs (context-free grammars) and 
NFAs (nondeterministic finite automata). CFGs and NFAs 
may be used as generators by providing them ‘advice’ on 
which nondeterministic branch to take at each step as input 
(e.g., [5]). This descent gives us at each stop a certain class of 
resource-bounded generalizations we can define. How do the 
other facets behave as we descend from a universal language 
to increasingly restricted metalanguages? 

• With each restriction in the power of the metalan¬ 
guage, the set of generators we can express becomes, 
of course, smaller. 

• In a universal metalanguage we have no useful guar¬ 
antees about the behaviour of the generator; as we de¬ 
scend the properties become stronger, e.g., in primitive- 
recursive we are guaranteed termination. 

• As we restrict the language, the program length re¬ 
quired to express generators (if they remain express¬ 
ible) increases. For at least some cases and if our steps 
are big enough, the increase in program length cannot 
be bounded by any computable function. 

• The time complexity of running a generator in a uni¬ 
versal language cannot be bounded by any computable 
function. As we descend generators are guaranteed to 
run faster and faster. NFA-based generators can run 
in nearly linear time. 

• As we restrict the language more properties become 
decidable, and they become easier to decide, for ex¬ 
ample, in primitive-recursive we are guaranteed termi¬ 
nation, for NFAs we can decide whether two generators 
are equivalent. 

• Our ability to use generators to compress patterns is at 
its peak in a general-purpose language; as we descend 
there may be commonly occurring patterns and mo¬ 
tifs that cannot be captured in the resource-bounded 
metalanguage. A classic example is Champernowne’s 
number 

0.12345678910111213141516171819202122••• 

that is easily generated in a universal metalanguage, 
but becomes incompressible in suitably restricted frame¬ 
works. For example, Lempel-Ziv compression is pow¬ 
erless against it since every subsequence occurs equally 
often, a so-called ‘normal’ real number [18, §1.9]. Simi¬ 
larly, the failure of simple parametric polymorphism to 



capture some useful patterns amongst types in generic 
programming can be viewed in terms of such patterns 
being ‘incompressible’ in the restricted metalanguage. 

• Inverting a generator (finding the parameters that will 
cause it to generate a particular instance) is undecid- 
able at the higher levels, and becomes easier as you de¬ 
scend. For example, the problem of inverting a CFG- 
based generator is simply parsing. For suitably re¬ 
stricted forms of CFGs the inversion problem is simply 
unification, for which very efficient algorithms exist. 

• The problem of finding a generator that generalizes 
a given a set of instances starts hard and becomes 
easier as the metalanguage is restricted. In a univer¬ 
sal language, the problem of finding a generator for 
one instance is closely tied to calculating Kolmogorov 
complexity, which is undecidable; in restricted meta¬ 
languages it becomes possible, for example there are 
algorithms to approximate the best context-free gram¬ 
mar producing a string (e.g., [5]). 

3. PRELIMINARIES 

To characterize the nature of these tradeoffs we employ 
some tools of computability theory as can be found in the 
introductory chapters of textbooks such as Cooper [6], and 
summarized here. We adopt the modernized terms for com¬ 
putability theory suggested by Soare [27], such as computably 
enumerable (c.e.) in place of recursively enumerable, com¬ 
putable instead of recursive, and so forth. 

From the vantage point of computability theory, a pro¬ 
gram represents a function from inputs to outputs, a par¬ 
tial computable function. The computability notations for 
these have a straightforward correspondence to notations 
from programming language theory. In the perhaps more 
familiar ‘Scott brackets’ notation, one writes |[p]] I 'a; for the 
value produced by a program p in language L running on 
an input x. The corresponding notation for partial com¬ 
putable functions is <p P (x), but usually some universal ma¬ 
chine (equivalently, programming language) is assumed and 
one writes <fi P {x). 

In computability theory it is traditional to consider ev¬ 
ery object as encoded by a unique natural number. The 
behaviour of a program is viewed as a partial function tp p : 
N —*• N, from input (coded as a natural) to output (coded as 
a natural), defined just for those inputs on which the pro¬ 
gram halts. Programs are likewise coded by naturals, for 
example by enumerating all valid programs in a language 
lexicographically and using a program’s index in this fist. 
(We will equate indices with programs throughout to mini¬ 
mize confusion.) The T P (x) notation is rather unfortunate 
for metaprogramming: to represent the behaviour of the 
program generated by a generator g with parameters x on an 
input y one would write Tv g (x) (y). (The notation [ [g]* ]y 
seems clearer). For consistency with the computability lit¬ 
erature we will use the ^-notation. The smaller inset box 
summarizes key notations for partial computable functions. 
Of these the most important are j (halts) and | (diverges). 

On occasion we shall employ the Church-Turing thesis to, 
when presented something computable, assert there exists a 
program i so that ipi computes it. 

The following fact will shortly be useful; it asserts that the 
partial computable functions are closed under composition. 


j Notations for partial computable functions j 

Tv 

Partial function computed by program p 

Tv{x) 

Output of p on input x 

<Pp(x) | 

p halts on x 

Tp(x) T 

p diverges on x 

Tp,k(x) | 

p halts in < k steps on x 

Tv = W 

p and p' compute the same partial function 

<p p (N) 

All possible outputs of p 


Fact 3.1. If ip x and <p y are partial computable functions, 
there is a program p such that ip x o ip y = ip p . 

In later sections we shall make use of the arithmetical 
hierarchy classes E°, 11°, and A°. These are summarized 
in Figure 1. 

4. A UNIVERSAL METALANGUAGE 

We wish to reason about metalanguages and the trade¬ 
offs they represent. If generators were expressed in very 
different languages, this would cause notational confusion. 
We shall instead fix a universal language, and require that 
every metalanguage be a restricted subset of the universal 
language. We can do this without loss of generality by not¬ 
ing that any metalanguage may be embedded in a universal 
language by means of pasting together an interpreter in the 
universal language with a generator and its input as a string. 
This provides a straightforward embedding of any language 
into the universal language. A typical example of such a 
construction is: 

int mainO 

{ 

print(Interpret_Lisp( 

"(lambda (x v) (plus x y))", 

"(1 2 )")); 

} 

string Interpret_Lisp(string prog, string input) 

{ 

} 

Such translations are easy to produce; it is easy to extract 
the original program from its embedded version; and the 
resulting program is longer by only a constant amount (the 
size of the interpreter plus a little extra). This is a so-called 
“two-part code” construction (interpreter plus program) [18, 
§2.1.1] and it preserves all the properties that interest us. 
We formalize these claims as follows. 

Claim 4.1. There is a universal language U such that for 
any metalanguage A, there is a computable function f trans¬ 
lating A programs to U so as to satisfy these properties: 

1. For every A-program p, the translated program f(p) 
has the same meaning, i.e., g> p = gJf( p )t 

2. We can computably recognize the programs that have 
been translated from A, i.e., /(N) is also decidable; 

3. We can computably reverse the mapping translation f; 

4- The translation adds at most a constant factor to the 
program size. 




The Arithmetical Hierarchy 

The arithmetical hierarchy was introduced by Kleene as a 
tool for classifying incomputable sets. It consists of classes 
of relations denoted E°, 11°, and A°, where n G N. The 
bottom levels of the hierarchy correspond to familiar classes 
of sets: 

• A? is the class of computable relations (equivalently, 
decidable sets); 

• E° is the class of computably enumerable relations 
(equivalently, c.e. sets or sets with an effective in¬ 
ductive definition); 

• n? is the class of co-computably enumerable relations 
(equivalently, co-c.e. sets or sets with an effective coin- 
ductive definition). 

The remainder of the hierarchy is defined in terms of rela¬ 
tions definable by restricted forms of first-order formulas: 

1. Eq = IIq = A° are the decidable relations; 

2. A relation is E ° +1 if and only if it can be defined by 
a formula of the form 3 y . R(x,y) with R G 11°, or 
equivalently is c.e. relative to a 11 ° oracle; 

3. A relation is II ° +1 if and only if it can be defined by 
a formula of the form Vy . R(x,y) with R G E°, or 
equivalently is co-c.e. relative to a E° oracle. 

4. a° = s° n n° 

The complement of a set S G E° is a set S G 11° and 
vice versa. The containment relations among the classes are 
illustrated by the following Hasse diagram: 



A? decidable 

That is, 

aJceJcAjCEjCA^c... 

a? c n? c a§ c n° c a° c • • • 

The superscript 0 on the classes indicates the arithmetical 
hierarchy; all of this hierarchy is enclosed in the first level of 
the analytic hierarchy which has superscript 1 and is defined 
in terms of second-order formulas. 

Figure 1: Summary of the arithmetical hierarchy 


Proof. (Sketch) Since the programming language A is as¬ 
sumed to be implementable on a computer, we can find 
an interpreter for A in the universal language U ; call this 
lnt(p,*). Define the translation function to be the equiva¬ 
lent of f(p) = Aa:.lnt(p,*). Then (1) follows from the use of 
an interpreter; ( 2 ) is guaranteed by the ability to examine 
the translated version and check that the interpreter is ex¬ 
actly the interpreter for the language A; (3) is ensured by 
adopting an appropriate “quotation” mechanism for the em¬ 
bedded program; (4) follows from the usual “two-part code” 
argument [18, § 2 . 1 . 1 ] □ 

We mention also that with a sufficiently powerful ma¬ 
chine model we can often devise efficient interpreters that 
preserve asymptotic time and space complexity up to some 
small overhead, e.g., logarithmic. 

In the remainder of the paper we assume, for tidiness, that 
metalanguages are all defined by decidable subsets of a fixed 
universal language. 

5. MULTISTAGE GENERATION 

We begin our investigation with some simple results con¬ 
cerning the power of having multiple stages, rather than a 
single stage. In multistage generation one has multiple gen¬ 
erators, each producing output taken as input by the next 
(e.g., [9, 28]). Assuming Church-Turing we consider each 
stage to be represented by a partial computable function. 
We may then make use of the fact that by definition, partial 
computable functions are closed under composition. The 
following result is then straightforward: 

Proposition 5.1. For every multistage generator there is 
an equivalent one-stage generator. 

Proof. This is a simple consequence of the class of partial 
computable functions being closed under composition. Let 
ip a , g>b, ■ ■ ■ , Pn be a ft-stage generator. Then by repeated 
application of Fact 3.1, there exists a program a such that 

P>a = Pa ° Pb ° • • ■ ° Pn- □ 

In some situations we may want additional input at each 
stage. This does not offer any additional theoretical power, 
since we can provide all these inputs up-front to the initial 
stage and thread unused inputs through to later stages. 

Most suitable programming language mechanisms offer 
function composition mechanisms that are succinct, i.e., the 
program length of the composed functions is only slightly 
higher than sum of the lengths of the individual functions. 
From this we can infer that multistage generation is no more 
succinct than one-stage generation. 

Although multistage generators are no more powerful than 
single-stage generators, they do have important practical 
use in distinguishing (say) generation, compilation, load and 
run-time stages. We are, however, justified in the remainder 
of this paper to consider only the single-stage case. 

6. TRADEOFFS IN SAFETY 

A primary concern in contemporary generator research is 
safety of generators. Some typical questions are: 

• Will the generator always halt and produce an in¬ 
stance? 

• Will the instance produced by the generator be syn¬ 
tactically well-formed? typable? semantically correct? 




• If a generated instance is not going to be correct, can 
we detect this and produce a sensible diagnostic mes¬ 
sage? 

• Can we devise restricted languages that ‘capture’ use¬ 
ful safety properties, e.g., every generator we write in 
the language always produces type-safe instances? 

As a prelude to tackling deeper questions, in this section 
we review the well-known phenomena that most functional 
properties of programs are undecidable, and explore the im¬ 
plications for generators. Readers familiar with Rice’s the¬ 
orem are encouraged to skip ahead. 

We can equate a safety property with the set of genera¬ 
tors having that property. For example, if we are concerned 
that the generator always halt, we can consider the set of 
generators that halt on every input. Some such sets lie in a 
special class called index sets in computability theory [ 6 ]. 

Definition 1 (Index set). An index set is any set of gen¬ 
erators BCN with the following closure property: if g £ B 
and g' is some generator with the same behaviour as g , i.e., 
ip g = (figi , then g' £ B also. 

We can view an index set as a functional property of gener¬ 
ators, i.e., a property definable only in terms of input-output 
behaviour and without reference to (for example) space and 
time consumption. 

The safety property ‘halts on every input’ can be repre¬ 
sented by an index set Tot containing every total computable 
function. 

Definition 2 (Total functions). Define Tot be the index 
set containing all total computable functions, i.e., generators 
that halt and produce an instance for every input: 

Tot = {g £ N | Va; . <p g (x) }} (1) 

The problem “Given generator g, is g £ Tot?”, i.e., wheth¬ 
er a generator always halts after some time and produces 
an output, is of course undecidable, as are most problems 
concerning halting. We might however wonder if simpler 
properties might be checkable, but this turns out not to be 
the case because of Rice’s theorem. 

Theorem 6.1 (Rice [23]). The only decidable index sets 
are 0 and N. 

It is a quick step from Rice’s theorem to proving that partial 
correctness of generators — if the generator halts, it pro¬ 
duces a safe instance — is undecidable. We model whatever 
safety property of instances we are interested in (type-safety, 
syntactic correctness) by a set Safelnstance of instances sat¬ 
isfying that property. 

Definition 3. A safety property of instances is a set Safe- 
Instance with 0 C Safelnstance C N so there is at least one 
safe instance and one unsafe instance— otherwise, the safety 
property would be trivial, i.e., always true or always false. 

Let SafeGenerator be the set of generators that only pro¬ 
duce safe instances: 

SafeGenerator = {g \ ip g ( N) C Safelnstance} 

(We write <p g (N) for the image of N under ip g , i.e., the set 
of all instances generated by g.) 


Proposition 6.1. The problem “Is g £ SafeGenerator?” is 

undecidable. 

Proof. This is straightforward: we prove SafeGenerator is an 
index set not equal to 0 or N and apply Rice’s theorem. 

Suppose i,j are generators with ipt = <pj and i £ Safe- 
Generator. Then y>i(N) C Safelnstance by definition. Since 
ifii = (p>j we have tfij( N) C Safelnstance and hence j £ 
SafeGenerator also. Therefore SafeGenerator satisfies the clo¬ 
sure property of Defn. 1 and is an index set. 

From the definition of a safety property there exists a safe 
instance s and an unsafe instance s. Consider the following 
functions: 

f(x) = s 
fix) =s 

Both functions are computable and therefore we can find 
programs g and g that compute them. Since g £ SafeGen¬ 
erator we have SafeGenerator ^ 0. From g' 0 SafeGenerator 
we have SafeGenerator ^ N. By Theorem 6.1, SafeGenerator 
is undecidable. □ □ 

So, the general question of whether a generator always 
produces safe instances is undecidable; this is a simple corol¬ 
lary to Rice’s theorem. By finding where this problem lies 
in the arithmetical hierarchy (Figure 1), we can obtain more 
precise details of its undecidability. For example, some prop¬ 
erties that are undecidable but E? can be approximated 
nicely— we can write a program that will try to decide the 
property within some time limit t, and as we let t —> oo 
we can get a positive answer if the property is true . 2 We 
operate under the assumption that the safety of instances is 
decidable. For example, it is decidable whether the instance 
is syntactically correct or typable; this reflects current prac¬ 
tice. 

Proposition 6.2. If Safelnstance £ A? then SafeGenerator £ 

n?. 

Proof. A generator is safe if and only if there is no input 
for which it produces an unsafe instance. We can therefore 
define the safety property by: 

SafeGenerator(t;) <-> -i(3a; . ip g (x) 0 Safelnstance) 



This is the negation of a E? formula, and is therefore n? or 
co-computably enumerable. □ □ 

It is worth noting that when we shift from programming 
to metaprogramming, the safety problem becomes harder: 
if instance safety is A?, then generator safety is n? (and not 
A?). We return to this theme in Section 8 , where we ask 
when “going meta” is accompanied by ratcheting up a level 
in the arithmetical hierarchy. 

That SafeGenerator is nl 1 implies we can approximate the 
property by searching for counterexamples, and if a coun¬ 
terexample exists, we will eventually find it. Unfortunately 
if we do not find a counterexample within a set amount of 
time we can conclude nothing about whether our generator 
is safe. 

An even harder problem is deciding whether a generator 
will halt for any input and also produce an output that is in 

2 This is the notion of a A^-approximating sequence [ 6 ]. 



Safelnstance. We show this problem is n^-complete, roughly 
speaking, as hard as any II2 relation. 3 

Proposition 6.3. Suppose Safelnstance is decidable and let 
ip(g) be the property “g halts on every input and outputs a 
safe instance.” Then ip(g) is Yl^-complete. 

Proof. First we show ip £ 11°. We can define ip(g) by the 
formula: 

ip(g) <-> (Vx . <p g (x) |) A SafeGenerator(g) (2) 


We have a universal quantifier afront a E° relation, making 
it n°; its conjunction with the 11° relation is 11°. 

The index set Tot is known to be II2 complete [6]; we 
reduce deciding Tot to ip(g). Given a query “Is / £ Tot?” 
we can construct a function f'(x) that evaluates / on x, and 
if this halts, returns a safe instance s £ Safelnstance. Then 
g £ Tot if and only if ip(g). This is a many-one reduction 
(see footnote) and therefore ip is II°-complete. □ □ 

So, this safety property is strictly harder than deciding 
the “partial correctness” property SafeGenerator. 

The safety situation for generators written in a general- 
purpose language is bleak: no nontrivial safety properties 
are decidable. This fact has motivated the design of special- 
purpose languages for generators that are able to guarantee 
some safety property. Of particular interest are languages 
that capture a safety property, which we investigate in the 
next section. 

6.1 Languages capturing properties 

As we have seen, interesting safety properties of genera¬ 
tors written in a universal language are undecidable. We 
might conjecture that to ensure a safety property we must 
sacrifice some classes of computations that can be done 
safely. Perhaps surprisingly, this is not always the case: 
we can sometimes sidestep undecidability by designing re¬ 
stricted languages that ‘capture’ the property, in the sense 
that every restricted program has the property, and con¬ 
versely, for every unrestricted program with the property 
there is a functionally equivalent restricted program. Con¬ 
sider for example the property ip given by “<p p (x) halts for 
at most a finite number of inputs x.” This property is un¬ 
decidable (in fact E2) but has a trivial language capturing 
it: allow only programs of the form 


in which any arbitrary generator can be run, but output 
is filtered and any unsafe instances are replaced with safe 
instances. This captures the property in a theoretical sense, 
but in practice we are fond of diagnostic messages and prefer 
compilation to always fail if ~np(p) holds. 

There are several relevant veins of research in capture of 
properties by languages: 

• Time- and space- complexity classes can be captured 
by restricted languages, an idea that goes back to the 
1960s and has a rich literature (e.g., [21, 24, 16]). 
There is a kind of ‘cheat’ method, which involves a 
clocked programming language where every program 
comes with an attached statement such as “run me 
for at most c|*| fc steps,” with c and k constants; in 
this case termination in polynomial time is guaran¬ 
teed. Then there are languages that capture com¬ 
plexity classes in a natural way. For example Neil 
Jones describes a family of languages with familiar 
constructs such as while, if and cons that capture com¬ 
plexity classes like PTIME by omitting selected con¬ 
structs from the language [17]. 

• Descriptive or Implicit computational complexity stud¬ 
ies restricted logics that capture complexity classes 
(e.g., [15, 19]). For example, polynomial time queries 
on ordered relational structures can be captured by 
first order logic augmented with a least fixpoint oper¬ 
ator. Some such results translate easily into program¬ 
ming languages. 

• Program schemes are restricted forms of recursion for 
which certain properties (e.g., termination) are decid¬ 
able [7]. 

We may hope to design metalanguages that capture safety 
properties in a similar way— this is essentially the goal of 
the MetaML research programme [25, 28]. We can use the 
tools of computability theory to reason about when a lan¬ 
guage capturing a property might exist and what properties 
it might have. 

In what follows we will consider properties ip(g) defined 
by arithmetical formulas as in the previous section. If a 
particular generator g satisfies a property ip{g), we say “ip(g) 
holds” or “ g satisfies ip”. 

Definition 4 (Capture). We say a restricted metalan¬ 
guage L C N captures a property ip when L is a decidable 
subset of generators, and 


( ci when x = xi 
C 2 when x = X 2 


1. Every program g £ L in the restricted metalanguage 
satisfies the property ip: 


f(x) = { 


(3) 


Vff € L . ip(g) (4) 


c„ when x = x„ 

, | otherwise 

for all finite n and arbitrary constants d,Xi for i < n. This 
language clearly captures the undecidable property ip. 

We could capture the property SafeGenerator - “every 
instance output by the generator is safe” — by a language 

3 The exact definition is: ip is II°-complete when ip £ 11°, 
and any relation <p £ 11° is many-one reducible to ip. A set 
( p is many-one reducible to ip when there is a computable 
function / such that g £ <p if and only if f(g) £ ip. 


2. For every (unrestricted) generator g' £ N such that g' 
satisfies ip, there is some equivalent (restricted) gener¬ 
ator g £ L such that (fi g = p g r. 

Vff' £ N . ip(g') —► (3g £ L . <p g = <p g >) (5) 

For example, if a metalanguage L captures the property 
“for all x, (fig(x) runs in 0(|a;| 2 ) time”, this means not only 
that every generator in L runs in quadratic time, but also 
that every computation that can run in quadratic time is 
expressible in L. 



First we consider the problem of metalanguages captur¬ 
ing functional properties, such as always generating safe in¬ 
stances or always terminating. 

Definition 5 (Functional property). A property ip(g) is 
functional when, equivalently: 

1 . "0 is defined solely in terms of termination and input- 
output behaviour; 

2 . ip is an index set; 

3. {ifg = <p g ,) -> (ip(g) ^ ip(g')). 

For example, whether a generator always produces safe in¬ 
stances is a functional property; whether it runs in quadratic 
time is not, and is considered a non-functional property. 
(The term non-functional is unfortunate but traditional in 
software engineering.) 

One way to design a language capturing a property is to 
package programs together with proofs of that property, as 
in proof-carrying code [22] or Royer and Case’s treatment of 
provably bounded programming systems [24, §4.3.1]. This 
yields a sufficient condition for the existence of a language 
capturing a property. 

Proposition 6.4. Let ip be a property for which there is a 
sound proof system hg, with the following properties: 

1. Checking whether a deduction R is a valid proof in the 
system \~g, is decidable; 

2. For every generator g satisfying ip, there exists an equiv¬ 
alent g' such that ip g = ip g i and there is a deduction in 
by, proving ip(g'). (This is strictly weaker than requir¬ 
ing the proof system to be complete for ip.) 

Then there is a language capturing ip. 

Proof. We follow the proof-carrying code idea, designing a 
language whose every program is a pair (<j,R) where g is 
the generator and R is a nonexecutable payload containing 
a suitably encoded proof of ip(g) in the system b^,. We define 
the language L to be only those ( g,T >) where R is a valid 
deduction proving ip(g); this is a A? subset because of the 
premise ( 1 ). 

We claim this language captures ip in the sense of Defn. 
4: Every generator in L clearly has the property ip, due to 
soundness of the proof system; and every generator g £ N 
such that ip(g) holds has an equivalent program in L by the 
premise ( 2 ). □ □ 

Languages that require programmers to attach proofs suf¬ 
fer from so-called “technology adoption issues.” Better per¬ 
haps to find a language that implicitly captures the prop- 
ery; such languages do not require programmers to explicitly 
write proofs. However, writing programs in languages that 
capture functional properties does have an implicit relation¬ 
ship to proofs: reworking a generator from a general-purpose 
language to a restricted language is tantamount to proving 
the property. 

Theorem 6.2 (Capture is tantamount to proof). Let 

ip be a functional property of generators, and L <Z ^ a re¬ 
stricted language capturing ip. Given a generator g' £ N 
satisfying ip, the problem of transforming it into an equiva¬ 
lent generator g £ L in the restricted language by means of 
(provably) semantics-preserving steps is at least as hard as 
finding a proof ofip(g'). 


Proof. We assume we have already a proof that L captures 
ip. At each step of transforming g' into g we can, by means 
of semantics-preserving steps, maintain a proof that the two 
versions are equivalent, so at the end of the process we have 
a proof that (p g = <p g /. Since L is decidable we can readily 
obtain a proof that g € L at the end of the process. We 
then have proofs of 

1. g € L (g is in the restricted language) 

2. V <7 £ L . ip(g) (from capture of ip by L) 

3. ip g = ip g f (from semantics-preserving steps) 

From (1) and (2) we obtain ip(g); from (3) and the premise 
that ip is a functional property we obtain ip(g'). 

Therefore the problem of proving ip(g') is reducible to 
transforming g' into the restricted language L by means of 
semantics-preserving steps. □ □ 

Related results on succinctness (Section 6.3) suggest that 
the reworked program may be as long as a proof of the 
property ip{g). 

Corollary 6.1. If ip is an undecidable property, there can be 
no automated (computable) process for reworking generators 
into the restricted language. 

The practical implications of this are that writing gener¬ 
ators in certain restricted languages is just as hard as prov¬ 
ing safety properties, and may require arbitrary creativity. 
However, there may be an important social difference: proof 
construction can be intimidating for programmers, whereas 
programming in a restricted language can be a source of 
interesting puzzles requiring ingenious solution. There are 
intermediate solutions between proof-carrying code and im¬ 
plicit capture, where we design a language with some mix 
of explicit proof and implicit capture of the property. Type 
systems are a prime example: the programmer annotates a 
program with enough type information to make type safety 
easily provable. From a theoretical perspective program¬ 
mers are constructing proofs of type safety relative to the 
decision procedure for the type system in the compiler; but 
it feels more intuitive than formal proof calculi. 

6.2 When is capture possible? 

So we may sometimes find languages that capture unde¬ 
cidable properties. In this section we give results on when 
such languages may or may not exist. There are some 
niches that can be carved out, though, for example the suf¬ 
ficient conditions of Proposition 6.4. We also know there 
are languages capturing any deterministic time and space 
bounds due to the existence of “clocked” programming sys¬ 
tems where programs are annotated with resource bounds 
[24]. 

Here is a negative result. We show that arbitrarily hard 
functional properties cannot be captured by programming 
languages, by turning the tables and characterizing a prop¬ 
erty in terms of the language capturing it. 

Proposition 6.5. If there is a language capturing a func¬ 
tional property ip, then ip € £ 3 . 

Proof. From the definition of capture (Defn. 4) and the key 
fact that ip is functional (Defn. 5), we have the following 



correspondence. 

V’(S') <-*■ V . fa 3 = </y) A (g G L) (6) 

n° a? 

The relation ip g = ip 9 / is II 2 , so if) is S 3 . □ □ 

This implies we cannot capture in languages any func¬ 
tional property not definable in E§, i.e., the whole span of 
the arithmetical hierarchy above E 3 is off-limits. However, 
this does not rule out the possibility of arbitrarily hard non¬ 
functional requirements being captured. 

Here is a well-known fact that sets the stage for proving 
we cannot capture the property “every generator g always 
halts and produces a safe instance,” i.e., total correctness of 
generators, in a language. 


any existing computer.”) An underlying cause is that we 
can pose problems easily solveable in an unrestricted lan¬ 
guage, but “look random” to the restricted language and 
one cannot do any better than decomposing it into a large 
number of cases, as in the above example. Problems that 
can be decomposed only into an infinite number of cases are 
inexpressible. 

Let us write | • | for the length of a program; such measures 
are usually required to satisfy the very weak axioms of Blum 
[2]. Counting bits of the representation is satisfactory. 

Definition 6 (Computably succint). Suppose L and L' 
are two languages. We say L is computably succinct relative 
to L' if for every program p G L for which there is a func¬ 
tionally equivalent program in L' , there is a p 1 € L' such 
that 


Proposition 6.6. There is no language capturing the total 
computable functions, i.e., the property Tot(p) <-> \/x . <fi P (x) |. 


b'l < f{\p\) 


where / is some computable function. 


Proof. Suppose L C N is a language capturing Tot; then 
every total computable function is expressible in L. We 
use diagonalization to construct a total computable function 
obviously not in L. Consider an enumeration {piof 
the programs in L; such an enumeration exists since L is 
decidable by Defn. 4. Consider the function 

fin) = 1 +p Pn (n) 

Since p n G L, this program halts on every input. It is also 
total and computable, and is therefore expressible in L. Let 
k be the L-program that computes it. Then ifik{k) = 1 + 
< pk(k ), a contradiction since z = 1 + z has no solution in the 
naturals. □ □ 


Proposition 6.7. If there are at least two safe instances, 
there is no metalanguage capturing the property “g halts on 
every input and outputs a safe instance. ” 


Proof. Following the same style of diagonalization argument 
in Proposition 6 . 6 , changing every safe instance on the diag¬ 
onal. (The diagonalization would fail if there was only one 
safe instance). □ 

6.3 Succinctness 

It is a well-studied phenomena that often when we move 
from one language to a more restricted version, some pro¬ 
grams have to get larger — a loss of succinctness. The in¬ 
tuitive reasons for this are demonstrated by revisiting the 
language seen earlier capturing the property “halts on only 
finitely many inputs” by programs of the form: 


( ci when x = xi 
C 2 when x = X 2 


f(x) = { 


c„ when x = x„ 
„ | otherwise 


Consider a program written in a general-purpose language 
that, given input x < IO 100 , outputs x + 1 , otherwise di¬ 
verges. This halts only on finitely many inputs, and can be 
implemented in a few lines of C code. The corresponding 
“lookup table” program in the above language is too long 
to fit into the observable universe. (If we scale down the 
exponent we can get the more practical “too long to fit into 


Saying one language is not computably succinct relative 
to another is a strong statement; for example, it implies 
that the loss in succinctness cannot be bounded by your 
favourite fast-growing computable function, for example the 
‘power tower’: 

10 

, n lo 10 ‘ 

r(fc) = io 10 

k 

where T(l) = 10, T( 2) = 100, T(3) = IO 100 , and so on. 
(Cosmologists suppose the number of atoms in the observ¬ 
able universe is less than T( 3).) 

All the Turing-complete languages are computably suc¬ 
cinct relative to one another, and in fact the interesting ones 
are all within an additive constant of one another; this fol¬ 
lows from a ‘two-part code’ construction [18, § 2 . 1 ], 

The tradeoff between succinctness and power of languages 
has been explored rather exhaustively, and we summarize 
only some highlights here. For details Royer and Case [24] 
is recommended for the subrecursive languages perspective, 
and Chapter 7 of Li and Vitanyi [18] is recommended for 
the Kolmogorov complexity viewpoint (concerned primarily 
with instance complexity rather than computable functions, 
but still interesting). 

Results on succinctness of languages fall loosely into three 
classes. 

1. Loss in succinctness when moving from one language 
to more restrictive language. The general flavour of 
such results is that if you restrict a language that can 
compute at least polynomial-time functions in a suf¬ 
ficiently strong way, the resulting loss in succinctness 
cannot be bounded by any computable function. The 
first such result was achieved by Blum [2], and similar 
results are abundant [24], 

2. Losses in succinctness between two languages of the 
same expressive power. For example, most introduc¬ 
tory theory classes cover the fact that nondeterminis- 
tic finite automata (NFAs) can be converted to DFAs 
with at most an exponential expansion in size. Note 
though, that both capture the regular languages. 

3. Losses in succinctness when moving back and forth 
between two languages of the same expressive power. 



For instance Hartmanis gives an example of two dif¬ 
ferent languages capturing PTIME, neither of which is 
computably succinct relative to the other [ 11 ]. 

With respect to languages capturing properties, we can 
make the following observation. 

Theorem 6.3. If a language L C N is computably succinct, 
then any functional property ip it captures is II®. 

Proof. Suppose L captures a property ip. As before we turn 
the tables and define ip in terms of the language: 

V’(S') <-► V • (<Pg = W) A (9 € L) (7) 

Since L is computably succinct, there is some computable / 
such that 

VKs) V < f{g) ■ {p g = <p g >) a (g' e L) (8) 

The addition of < f{g) turns the existential quantifier into 
a bounded quantifier; therefore ip(g) £ IlS. □ □ 

7. CHASING PROPERTIES 

When our attempts to capture a property by a language 
fail, there remains the possibility of approximating the prop¬ 
erty. For example, although total correctness of generators 
cannot be captured by a language, we can choose some re¬ 
stricted language as a starting point and gradually build it 
up so as to increase its power and succinctness. 

We can model this process by a chain of languages Lo C 
L\ C 1/2 • • - converging towards the desired safety property 
ip. Note that given Li we can always find a set Li C Li+ 1 C 
ip, for example, by adding a finite number of special cases 
to the test for Li. But in practice we find a slightly stronger 
proof system, capture some common patterns, and so forth. 
We call this chasing a property. 

Let us write C{Lf) for the length of the shortest program 
deciding the set Li. 

Proposition 7.1. Let ip be an undecidable property of gen¬ 
erators, and Lo C L\ C L 2 ■ ■ ■ a countable (but not c.e.) 
sequence of languages, each decidable, such that: 

1. Each language Li has the property ip{p) for every p £ 

U; 

2. U !fcN Li = ip, i.e., in the limit we recover exactly the 
language ip; 

Then, limi_,oo C(Li) = 00 , i.e., the length of program re¬ 
quired to describe the language Li diverges. 

Proof. If C(Li ) did not diverge, we would have a finite 
program deciding the undecidable property ip, a contradic¬ 
tion. □ 

So, in essence the best one can hope for is to capture the 
perfect metalanguage in the limit by approximating it from 
below with ever-more-complicated languages. This is the 
conservative approach. 

An optimistic approach is to start with the universal lan¬ 
guage Lo = N, which fails the safety property, and find 
languages lo D L 3 I 2 D that gradually winnow out 
the unsafe cases and converge toward ip, with ever-more- 
complicated languages. 


These two approaches — approximating ip conservatively 
from below or optimistically from above — appear to rep¬ 
resent irreconcilable approaches to metaprogramming lan¬ 
guage design with no middle ground. I would propose Meta- 
ML as representative of the first, and C++ as emblematic 
of the second, particularly the C(Li) —> 00 part. 

8. WHEN IS “GOING META” A JUMP OF 
TURING DEGREE? 

When we make the shift in perspective from programming 
to meta-programming — “going meta,” as it were, what 
happens to the difficulty of verification problems? How does 
the hardness of these problems relate: 

1. Does a program p satisfy a property ip? 

2. Does every program generated by a metaprogram g 
satisfy a property ip? 

These questions suggest a connection to the jump operator 
in computability theory. We define an operator on proper¬ 
ties in the following way: 

Definition 7 (Meta-jump). Let ip(p) be a property of 
programs. The meta-jump of ip is the property ip* given by: 

ip\g)&Vy . {g>g(y) |) -*• f(<p g (y)) 

g halts i/> holds for its output 

i.e., we shift from the property of a single program ip(p) to 
the property ip(p) holding for every program p produced by 
the metaprogram g. 

We might expect ip^ to be much harder to decide than ip, 
but this appears not to be the case. 

Let us use formula syntax to roughly characterize the ac¬ 
tion of the meta-jump operator. The meta-jump adds a V 
quantifier at the start of a formula. Based on this syntactic 
characterization we can immediately get: 

Proposition 8.1. The meta-jump operator satisfies the fol¬ 
lowing rules: 

1 . if ip e E° thence n£ +1 . 

2 . if ip e n£ then ip* € n£. 

Note that (2) implies that the meta-jump has no effect 
on the placement of formulas that are n$! but not A®. The 
condition ( 1 ) states that it is possible for properties to 
become harder under the meta-jump, but this is not neces¬ 
sary because of the inclusion A® cEjc n° +1 . (Note that 
this characterization is very rough and does not consider 
finer degrees of undecidability such as m-degrees). 

It turns out that the safety properties usually talked about 
in connection with metaprogramming and program genera¬ 
tion are all in the form n°: halting, always producing a safe 
instance, both halting and producing a safe instance, for ex¬ 
ample. We usually conceive of a safety property as prevent¬ 
ing certain some (usually infinite) set of failure conditions 
from occurring. We can enumerate the failure conditions 
and check them one by one; if a failure condition occurs we 
know the safety property fails. This style of safety condition 
is always n? relative to some relation, and therefore there is 
no jump in the level of the arithmetical hierarchy when we 
‘go meta.’ 



9. CONCLUSIONS 

We set out to characterize tradeoffs in metaprogramming, 
in retrospect a somewhat presumptuous goal, since the prob¬ 
lems turn out to be unexpectedly deep and requiring further 
investigation. The computability approach is very useful in 
providing quick and coarse characterizations of tradeoffs. 

One result that remains elusive is a characterization of 
the tradeoff between safety and expressive power involved in 
metalanguages having the property “every instance is type- 
safe.” The primary challenge is that in a general-purpose 
metalanguage one can always satisfy the capture proper¬ 
ties vacuously by introducing layers of interpretation, and a 
way to disallow these ‘cheats’ is not apparent without drop¬ 
ping to a subrecursive metalanguage. Partial correctness of 
metaprograms is a ‘run-time manageable’ property, in the 
sense that one can detect bad outputs before they happen. 

Despite these difficulties a rough picture of the major 
tradeoffs in ‘safe metaprogramming’ emerges. 

1. Total correctness of generators cannot be captured. If 
termination of the generator is required, one must pick 
a suitable subrecursive language and try to recoup suc¬ 
cinctness and power as needed by building in provably 
safe ‘escapes’ back up to more powerful classes of gen¬ 
erators. 

2. Whether there are languages capturing partial cor¬ 
rectness of metaprograms in a useful way is uncer¬ 
tain. However, we can say that if such languages exist, 
and are not vacuous, then we expect because of Theo¬ 
rem 6.2 that reworking generators into such languages 
is as hard as proving partial correctness. However for 
social reasons ‘capture’ is more desirable, if it can be 
achieved. 

3. When we restrict the power of metalanguages, we lose 
the ability to compress certain kinds of motifs and pat¬ 
terns. Whether this causes a practical (rather than 
theoretical) loss in succinctness depends on the char¬ 
acteristics of the problem domain (cf. [29]). 

To summarize, we can say that there is choice between two 
strategies when designing a metaprogramming language. One 
can give safety primacy, start with a restricted language, and 
try to build up the complexity of the language so as to re¬ 
capture lost power and succinctness. Or, one can give power 
primacy, start with a universal language, and try to build 
up the complexity of the language so as to capture necessary 
safety properties. These represent fundamentally different 
attitudes toward metaprogramming. 
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